The second part might be a bit blurry at times as I had to throw together four thousand words in two days! But if you have any questions, feel free to e-mail me. My e-mail address is: prozaq@usa.net
--==< Table of Contents >==--
I. Intro
II. Super ResEdit
III. Using Super ResEdit
IV. Other Uses of Super ResEdit
V. Variations to The Same Theme
VI. Pay Attention!
VII. Another Cracking Example
VIII. End of Part 2
--==< Intro >==--
Let me start off by refreshing your memory as to what happened in Part 1 of “The Ultimate Mac Cracking Guide”. I guided you through how to use MacsBug to find the conditional branch that decides whether the reg. number you entered is valid or not. At this point a couple of things can happen. The first situation is the best for the cracker! The program you’re trying to crack is glad that you registered your software, updates the preference file, and bothers you about registering no more! In this case you won’t need ResEdit or any other materials! Be glad that you’re quest to crack the software was successful!
But life ain’t that sweet! If the above situation occurs you are really lucky, as most softwares are a hell of a lot harder to crack! If the registration box still appears after relaunching the application then it’s probable that the following situation occurs. The program checks the registration number every time you launch the application, or several times while the application runs. This is when we have to change the source code using ResEdit (The only difference between ResEdit an Super ResEdit is that the later one contains an assembly code editor that allows you to view the contents of the CODE resource as assembly commands, not only as hexadecimal machine codes. Whenever I use the word “ResEdit” I am in fact referring to Super ResEdit!)
--==< Super ResEdit >==--
OK, launch ResEdit and let me explain a bit! The Mac OS divides a file into two parts. It’s first part is the “Data fork”, where it keeps data, such as the ASCII characters in a text file. The second part is the “Resource fork”, this is where the action is! The resource fork contains information of the application such as how the application’s dialogs look like, how it’s custom windows look like, how the icons appear in the Finder, what ASCII strings the application will put in error dialogs and a lot more! In order to keep the Mac as user friendly for the software developer as possible, Apple provides a very humane way to create and edit resources through ResEdit. I will not go through what all the different resource types are used for, as that would take a hell of a long time! But here are the resource types of interest to us:
CODE - This is where the program’s codes is stored in assembly format. These are the commands the program executes once it is launched from the Finder.
CDEF - Same use as CODE. It is used in control panels.
cdev - Same use as CDEF.
INIT - Same use as CODE. It is used in system extensions.
DITL - This is where the design of a dialog box can be found. Where the buttons and text fields are designed and can be edited.
DLOG - Where the position of a dialog can be changed.
ALRT - Where the position of alert boxes can be changed.
WIND - Where custom windows can be designed.
I can recommend that you play around with ResEdit for a while and get a feel for how it works! HOWEVER! ALWAYS work on a COPY of the application you want to change! Since ResEdit is directly messing around with the structure of the program, if you mess up anything you can definitely screw up the application (and if you’re lucky your system).
For now I will focus on the “CODE” resource (and all other resources that serve the same purpose). Whenever anyone writes an application, in whatever language, their compiler converts the code into assembly. In assembly every command has it’s machine language equivalent, which is stored as hexadecimal information. So the CODE resource contains these hexadecimal assembly instructions. When you open up an ID from within CODE resource, then a large window should appear with a bunch of assembly commands and other nice info in it. (If ONLY a small window appears with a bunch of hex numbers in it then you don’t have Super ResEdit!) If both the big and small windows appeared then that’s good since you’ll need both. If only the big window appears select “Always Open” from the Hex Editor menu. This should bring up the small window with hex numbers in it. The small window represents only the hexadecimal values of the assembly commands while the big window translates these commands into a more perceptive human language (if you can call assembly human).
Now if you have the big window up you’ll see 6 columns of information, each of them representing one of the following things (from left to right):
Offset, Address, Opcode, Operand, Comment, Hex.
The Offset column represents the of the command with respect to the first command in the subroutine.
The Address column represents the commands position from the first command in that resource.
The Opcode section contains all the commands, and the Operand column contains which registers are affected by the command.
The Comment column helps you see what type of info is moved around.
And the Hex column shows what the opcode and the operand section turns into when it’s translated to machine language.
The beginning of the different subroutines are represented by a name in red, bold print on the left side of the window. Usually these are just called “Anon#”. You can see a list of all the subroutines in the Modules menu.
--==< Using Super ResEdit >==--
So what’s all this good for? Well... as I said before, most programs contain more security then the program discussed in part one of The Ultimate Mac Cracking Guide. Imagine the following situation:
You crack a program with MacsBug. You know this because the “thank you registering” dialog appears. But the next time you launch the application it asks for the reg. number again. What this CAN mean is that after you crack the program with MacsBug the program stores the information you entered in either a preference file or in a resource. And every time you launch the program it checks to see if the reg. name and number match. So in theory if you change the conditional responsible for the validity of the reg. number in the application itself, then it doesn’t matter how many times the program checks, as the reg. number you entered will always turn out to be a valid one!
And this is where we use Super ResEdit. Let’s say that we have established that the application checks for the reg. number every time it starts up. It is likely that the application uses the same subroutine to check the reg. number at startup as it used when you entered the reg. number in the reg. dialog.
So to use the example from part one, here’s what I found out from MacsBug:
And after following through the code I know that the subroutine in 134 does the conversion of the registration number I entered and at offset 13C the conditional checks whether my reg. number is the same as the valid reg. number. When I was dropped into MacsBug after I initiated the “modaldialog” atrap the following information was given to me by MacsBug:
D_PERSONALIZE
+0009A 010E7956 _ModalDialog ; 0028D906 | A991
This means that the modal dialog trap occurs in the subroutine D_PERSONALIZE. Most often though, you will be given something like this by MacsBug when encountering an atrap:
A-Trap break at 00D1A908 'CODE 0002 1B8C'+02E88: A97C
Here’s what the two sets of info mean. The first one means that the person who wrote the software decided that he will make life easy for crackers and called the subroutine dealing with registering the software “D_PERSONALIZE”.
The second info means the following: The atrap occurred in the resource “CODE” with resource ID 0002. And this is all we need to know! If you open up the application with Super ResEdit and open up the CODE resource with an ID number of 2 you can go to the offset given to you by MacsBug.
If the situation is like the one in the first example where only the name of the subroutine is given then you have to go through each ID number in the CODE resource and look for a subroutine called “D_PERSONALIZE”. You can find a list of all the subroutines used within an certain ID in the Modules menu.
So let’s say the following I get the following info in MacsBug once I step through the code after the modaldialog atrap:
A-Trap break at 00D1A908 'CODE 0002 1B8C'+02E88: A97C
So, lets say that I wanna change the conditional at offset 13C in the source code of the application so that it will branch every time no matter what!
I open the application with Super ResEdit and open up the CODE resource, I open up the resource with ID 2. Then I have to find the offset at 13C. You have to realize that the large window that disassembles the assembly code is only for viewing. Meaning that you can not change anything there! You have to work with the small window containing the Hex Editor info if you want to find and change things.
So I make the Hex Editor the window active. This brings up a new menu. The “Find” menu. This allows me to search for hex strings, for ASCII strings or offsets! And since I wanna search for an offset I activate the search for offset dialog and type in 13C. After I hit the Find button two digits are selected in the Hex Editor window (for this example the two digits selected would be 67). If I now activate the big window, I should be at the offset 13C. Meaning that I should be seeing exactly what was displayed to me by MacsBug. Now I could have a closer look at what was going on if I needed to!
So I know that I need to change this assembly instruction:
When MacsBug displays a command it shows me the hex equivalent of the command too! It is always the hex number appearing after the “|” sign. (I underlined it and put it into a bold print above). This hex number can be between 4 and 16 digits long. I know that I have to change the BEQ.S command to a BRA (Branch always) command. So I activate the Hex Editor’s window and type “60”.
In machine code all branch routines start with a 6. The BRA command is the number 60, and that’s why I replaced 67 with 60. I DIDN’T change the second half of 6704, as “04” contains the information regarding where the conditional should branch to! If I change “04”, then the program will branch to a bad offset and will most likely cause my computer to crash!
Now, if I DIDN’T want the conditional to branch, I could simply get rid of the command. However, simply deleting 4 digits is not the way! Just deleting 6704, will most likely cause the program to crash! Instead, I will replace the conditional by a NOP command. NOP stands for no operation. Meaning that the processor will not execute any operations for that command. It will simply jump to the next command in line.
To change the conditional instruction to never branch, activate the Hex Editor window and highlight the next two digits as well (so all together I will now have four digits selected “6704”). Then I would type “4e71” (as this is the equivalent of NOP in machine language). If I now go back to the big window, I can see that the command has been changed to NOP! Success!
Now I would save my work and try and run the application again. If it freezes I have goofed up somewhere. If not, lets test it! At this point, however, I will no longer have to crack the programs registration dialog with MacsBug, as I have changed the code within the application to do what I want it to do! So I could just enter anything I wanted as a reg. name and number. If the program says that I entered the wrong registration number, then I goofed up in cracking the program with MacsBug! I have to start from the beginning and look for another conditional.
If I’m lucky, then everything goes fine, and when I relaunch the application it will say that it is registered to me.
---===< Other Uses of Super ResEdit >===---
ResEdit is not only useful if you want to change the assembly code of an application! You can use it to help you through the process of cracking. For example, I almost always start off with opening up the program in ResEdit and look around amongst the dialog resources. I’m looking for the “thanx for registering” dialog. I write down it’s ID value and if I see that number being mover around in MacsBug than I know that I’m on the right track! I also try to find the “wrong number” dialog just to see how it looks like! You may also find hidden pictures and shit like that with ResEdit! ResEdit ROCKS! Handle it with care and it’ll be good to you! Mistreat it and it’ll screw up your computer!
--==< Variations to The Same Theme >==--
Up ‘till now, the situation was that the program used a subroutine to do calculations with the reg. number you entered and then returned from the subroutine and checked to see whether the reg. number you entered was valid or not.
Now, there is virtually an infinite amount of ways to protect software, and software developers know this! And if they are smart they will use various tricks to protect their softwares!
Another situation you might find yourself in, while cracking a program, is that there are two conditionals you need to change! This means that within the subroutine that checks the reg. number you entered, the program sets two flags. One of the flags is representing that the reg. number is correct or incorrect, and the second flag tells the program whether to update itself to the registered version or not! This is again a simple example. The developers of the program might have done something ingenious, so it might be a lot more complex than that!
If, however, this is the situation, then you will have to find the two conditionals and change BOTH of them accordingly!
---===< Pay Attention! >===---
Therefore, it is extremely important that you know exactly what the hell is going on in the program! When you step through a code in MacsBug pay attention to what is happening to the address registers! When you see that A0, A1,A2 or A3 contains your reg. name or reg. number then you know that you are getting closer! Also look out for the hex value of the reg. number you entered. For example, if you entered “12345” as a reg. number also look for its hex equivalent “3039”! If you see commands like: cmp.l 130(a6),d0
and don’t know how to access that specific part of the memory, then simply type: “dm a6+130” into MacsBug and it will show you the info that is contained 130 bytes away from a6’s current position. If you can’t figure out what a command does, refer to the “List of Assembly Commands” file (included in HackAddict 8 as Appendix A). And if you still can’t figure out a command then mail me! And remember! Nothing is uncrackable! It’s merely a matter of time! If you sit around for long enough you will figure out what the little bugger does and then you’ll also figure out how to crack it!
---===< Another Cracking Example >===---
I will now guide you through how I cracked a control panel recently. I will not mention any names as I just want this to be a theoretical example to what protection schemes you may encounter. Also this might give you an idea to what you might be doing wrong! What you might be spending too much time on, and things like that!
Cracking the control panel seemed at first as a piece of cake, as the control panel had a subroutine followed by a conditional. So I changed the conditional, and since nothing happened I thought I cracked it! But then I started to look around in the program with ResEdit, and I noticed that the program created STR# resource with my information in it! And since I didn’t get a “thanx for registering” dialog, I was a bit skeptic of my success!
So I deleted the STR# resource and started from the beginning again! But again when I changed the conditional the program added the STR# resource to itself! “Very fishy” I thought! So I started to take a closer look in it with ResEdit! I didn’t find a “thanx for registering” dialog. So I got curious and found in HackersHelper the registration number for an older version of the control panel. I tried the serial number given in HackersHelper and presto! An error dialog greeted me informing me that I was using a PIRATE registration number! What do you say to that? Never had that happen before! Very ingenious if you ask me!
So I found an older version of the control panel on a shareware CD of mine, and when I used the pirate reg. number on that one it worked! And as it turned out the program didn’t put up a “thanx for registering” dialog, but simply wrote “registered to ProZaq” in the upper left corner. Tricky! Very Tricky!
But now at least I knew that I have to follow through that subroutine before the conditional! So I did! And the damnest thing happened! Before long I found myself in the subroutine responsible for comparing the reg. name I entered to the reg. names given by Hackers Helper and HackUser! Now this was a hell of a subroutine! It was gonna compare my reg. name to that of a pirate one about 30 times! I found this out from looking into one of the address registers! So here’s a trick to do when you’re faced with a similar situation. Let’s say that you’re stuck in a subroutine like this:
Shit_routine: (name of subroutine)
add.b 1,d0
blah
blah
blah
blah
another 100 blahs
cmpi.b #1000,d0
bne shit_routine
cmpi.b d3,100(a6,d0)
rts
What the subroutine does is unimportant! The important thing is that it does the same shit 1000 times! After every “blah” it compares the value of d0 to 1000 and if it doesn’t equal 1000 it adds 1 to d0, and does the “blah”s again. Now for the computer 10000 instructions won’t take long! But for me to sit around and press return 10000 times would take a bit too long! So here’s the solution. Use the break command in MacsBug! Just issue MacsBug the command “br addr” where “addr” is the address of the command you want the processor to halt at! For example, in MacsBug the last command I gave you in that example subroutine, might look something like this:
+0013C 00D2E798 CMPI.B D3,100(A6,D0)
So if I wanted to be dropped into MacsBug every time the processor executed that specific instruction I would issue the command “br d2e798”. Make sure that you don’t use the offset with the plus sign in front of it! (in this case 13C) (You clear break points with the “brc” command. For more info on using break points type “help br” in MacsBug)
And so after I used the break command, I regained control of the computer after the program was done checking for the pirate names! Then I found myself in the subroutine responsible for putting my reg. number under an algorithm. And once it was done doing that, I found out that it checked to see if my reg. number was a valid one, and if it was it set TWO flags! It made both d1 and d7 equal one! (I must say that either this code was written with a horrible compiler, or it wasn’t optimized at all! I could have written the same damn algorithm in assembly, so that it would have taken about half as many commands to achieve the same thing!)
And after that there was a conditional within the subroutine checking to see if the hex value of the reg. number I entered (stored in d0) equaled that of the correct one (stored as an offset to A6). And it was a good thing that I left a br mark at this conditional by an accident because the program rechecked my reg. number four more times before it accepted that I entered the right reg. number! What a bitch!
And since I followed through the code thurally I also found out what algorithm it used to derive the correct reg. number! So if I wanted I wouldn’t have needed to change anything in the program! I could simply calculate what reg. number would be valid for the reg. name “ProZaq” and simply enter that in the registration dialog!
I did however also change it’s code with Super ResEdit. I changed the conditional that the program referred to 4 times! And so the next time I could enter any reg. name and any reg. number and it would accept it!
So here’s a summary of what types of security precautions the software used!
1. It checked to see if my reg. name was that found in HackersHelper or HackUser. This is a very unusual thing to do! I’ve never seen software of this caliber do this before!
2. It did a bunch of calculation with my reg. name. Almost all programs with serial number protections do this!
3. It compared the reg. number I entered to a valid one. Again, this step is used by most softwares!
4. If these two numbers were equal it set two flags, one in d1 and one in d7. Quite a common technique. Makes life a bit of a bitch!
5. It rechecked 4 more times whether the reg. number I entered was valid or not. G’Damn! Give it a break! Most programs (of this size) only check for the validity of the two numbers once or twice! But since it was the same conditional that did the checking, after I changed it with ResEdit, I could enter any reg. name and number I wanted!
